InfoMagic Internet Tools 1995 April/Internet Tools.iso/dos_win/winsock/maillist/93-10.Z/93-10/text0207.txt

Text File | 1993-10-18 | 7.4 KB | 176 lines

>> >       WinSock related question:
>> >          Does WSAGetLastError() return 0 when the last WinSock call
>> >       was successful?
>> >
>> >          Bob Quinn of FTP Software thinks that calling it without a
>> >   SOCKET_ERROR return from a function is against the 1.1 spec...
>>
>> Specifically, in a private message to Ian I cited the fact that
>> the v1.1 specification does not explicitly say WSAGetLastError()
>> can be used to indicate the success of the previous function.  It
>> says "this function returns the last network error that occurred.
>> When a particular Windows Sockets API function indicates that an
>> error has occurred, this function should be called to retrieve the
>> appropriate error code."

I believe that there was unanimity during the design meetings that a
successful call would _not_ modify the internal error variable accessed
via WSAGetLastError(). The intention was to mirror the semantics of the
Unix "errno" variable - indeed it is possible to #define errno as a
call to WSAGetLastError() in certain circumstances.  And errno is
definitely _not_ cleared on a successful call. Here's the text from
"man -s 2 intro". (This will probably call down USL lawyers on my
head...:-) The final sentence is the key.

     This section describes all of the  system  calls.   Most  of
     these calls have one or more error returns.  An error condi-
     tion is indicated by an otherwise impossible returned value.
     This is almost always -1 or the NULL pointer; the individual
     descriptions specify the details.  An error number  is  also
     made available in the external variable errno.  errno is not
     cleared on successful calls, so it  should  be  tested  only
     after an error has been indicated.

>> The most significant reason *not* to use WSAGetLastError() after
>> a function succeeds, though, is that it's unnecessary.  It incurs
>> useless overhead.  Why would an application call WSAGetLastError()
>> to see if a function succeeded when every function indicates success
>> with its return code???

Wrong. The "most significant reason *not* to use WSAGetLastError()
after a function succeeds" is that the call would reflect the most
recent error from a failing call. In other words, the successful
function call would appear to have failed! (Actually, I'm sure Bob
meant to say this, but his language suggested that maybe after all it
was just a question of efficiency. It isn't.)

Geoff
From [e-mail]  Fri Oct 15 18:43:56 1993
Received: from mica.inel.gov by SunSITE.unc.edu (SMI4.1/FvK 1.02)
          id AA26458; Fri, 15 Oct 93 18:43:56 EDT
Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov
    (4.1/INEL-MH-10.0) id AA19946; Fri, 15 Oct 93 16:43:04 MDT
Received: by dewey.inel.gov (5.65/INEL-WKS-2.0)
    id AA18822; Fri, 15 Oct 1993 16:43:14 -0600
Date: Fri, 15 Oct 1993 16:43:14 -0600
From: [e-mail] (Dave Brooks)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: More than one ASYNCGETHOSTBYNAME?
In-Reply-To: <[e-mail]>
References: <[e-mail]>

Mark Cox writes:
 > We were playing with winsock code last night and wrote a bit that
 > did a gethostbyname for both the socket and peer.   If we fire up
 > two asyncgethostbyname's they strangely both return the same handle
 > and only one ever completes.

I suspect that could be a problem with Lanera.  I fire up multiple
WSAAsynchGetHostByName's from several commercial stacks; the handles have
always been kept straight and they do eventually return.

 > Does this mean that you can only do one non-blocking gethostbyname
 > at once,  or is it that the Lanara (demo) Winsock has a problem?  We
 > looked in the Winsock spec but couldn't find anything to say that
 > doing more than one wasn't possible.

You can do more than one at a time; I suspect the limitation on the total #
of simultaneous calls is vendor specific and/or related to available
resources at the time of the call.

Let's see, the spec says WSAEWOULDBLOCK means that the asynchronous call
cannot complete at this time due to resource or other WinSock restraints.
So, they do tell you if you try to start up more asynchronous calls than
can be handled for whatever reason.  Hm, I'll have to deal with that in my
code as an opportunity to 'try again later', though right now I treat it as
an error.

It's true that the spec doesn't spell out some things about doing it 'the
right way'.  I posted a few months ago about multiple
WSAAsynchGetHostByName's, and the overwhelming response from vendors was
that you use a separate hostent buffer for each concurrent call, but other
than that they are supposed to work correctly.  I attended WinSockathon III
in August and brought up the point that this wasn't clearly documented, if
at all; they agreed and indicated that it should be cleared up in the next
release of the spec.  Ok, that's my interepretation, not a commitment on
their part; but that's how I took it.

Sorry, I have no idea when the next issue of the spec will be.  Since I
don't work for a vendor I'm not in that process :-)

Dave

-------------------------------------------------------
David L. Brooks
Idaho National Engineering Lab.  INTERNET: [e-mail]
POB 1625                         Phone: [phone]
Idaho Falls, Id. 83415-3730     FAX:   [phone]
-------------------------------------------------------
From [e-mail]  Fri Oct 15 18:57:53 1993
Received: from huey.wst.com by SunSITE.unc.edu (SMI4.1/FvK 1.02)
          id AA27082; Fri, 15 Oct 93 18:57:53 EDT
Received: by huey.wst.com (4.1/SMI-4.1)
    id AA11735; Fri, 15 Oct 93 17:59:41 CDT
From: [e-mail] (Alun Jones)
Message-Id: <[e-mail]>
Subject: Re: Tom Nemeth's apparent confusion with the new winpkt.
To: [e-mail]
Date: Fri, 15 Oct 93 17:59:41 CDT
X-Mailer: ELM [version 2.3 PL11]

Tom Nemeth said:
> Peter Tattam said:
> >>So to modify your installation you need to do the following...
> >>change all lines of the form
> >>    winpkt <winpkt_vector> <normal_vector>
> >>to
> >>    winpkt <normal_vector>
> >>e.g.
> >>    winpkt 0x60 0x61
> >>becomes
> >>   winpkt 0x61
>
> One big problem with this:  if you have multiple packet drivers loaded
> (ie. 2 network cards) how do you attach a winpkt to the second card?
> I think you should put the second parameter back to the way it was, so
> you would then have:
>     * TOTAL downwards compatibility with previous versions, and
>     * ability to support multiple network cards.
>

It appears you have become confused.  The vector that you pass to
winpkt is the vector that your packet driver is loaded at.  The
removed parameter (which WAS the first one) specified a NEW address
that the winpkt program would run on.  The up-to-date version CAN be
used with more than one card:

ne2000 0x61 3 320
3c509 0x73 5 300
(for example)
To load winpkt on the 3c509:
winpkt 0x73
To load it on the ne2000:
winpkt 0x61
(And there's nothing stopping you from doing both, if I'm not very
much mistaken!)

> Please consider!
>

Please consider that I much like this new version - you simply have to
find ONE interrupt vector that's unused, rather than two (and having
to make sure for some programs that the winpkt vector was lower than
the non-winpkt!)  I would guess a neat feature would be to remove the
one remaining parameter to load onto the first (non-winpkted) packet
driver!

> Tom Nemeth
>

Alun.
~~~~